1. Field of the Invention
This invention relates to an improved pacing method for call origination management systems, and more particularly to a call interrupt method to minimize the number of client-answered calls for which there is no operator available (so-called nuisance calls).
2. Description of the Prior Art
Call origination management systems automatically dial clients, listen for the call result (i.e., ringing, busy signal, answer, no answer, etc.), and when a call results in an answer, automatically transfer the call to an available operator. Such systems are in general use today by a variety of businesses, groups and organizations.
FIG. 1 shows a system overview of a typical prior art system. The heart of the system is a main system unit 10, which typically includes central processing unit. (CPU), telephone line control unit (LCU), hard disk storage 11, and a tape drive 12. A plurality of outbound telephone lines 13 are connected to the system unit 10. The number N of these outbound telephone lines typically is on the order of 48, but may be more or less depending on the specific application. A plurality of voice and data terminal stations 14 are also connected to the system unit 10. The number M of these voice and data terminal stations may be, for example, 24 for the case where the number N of the telephone lines is 48. In other words, the number M of the voice and data terminals is less than the number of telephone lines. This allows the system unit 10 to dial calls while all operators are busy talking to clients.
As illustrated in FIG. 1, each of the voice and data terminal stations comprises a combination video display terminal (VDT) and keyboard 15, and a telephone headset and microphone 16. FIG. 2 illustrates a typical operator screen as displayed by the video display terminal. When a call is transferred to an operator, a portion of this screen will already have been filled in by the CPU in the main system unit 10. Specifically, section 20 of the screen providing the name, address and telephone number of the client, will have been filled in so that the operator knows immediately who has been called. During the course of the conversation, the operator may confirm the data and, if necessary, make corrections using the keyboard. Section 22 of the screen is also filled in automatically by the CPU, based on the log-in data from the operator at the beginning of the campaign and the CPU's clock and calendar. The top portion 24 of the screen is available to be filled in by the operator with any pertinent information from the contact with the client. In addition, where a bill is to be paid or a pledge made that is to be charged to a credit card, the operator would fill in portion 26 of the screen during the call.
FIG. 3 illustrates the data flow of the system. The first step in beginning a calling campaign is to obtain the calling data, typically via tapes 30, disks 31, or through a communication link to a host computer 32. The data is input at 33, and the system then organizes the data into the records for the campaign. When the campaign is started, the data is loaded into the "input call list", as indicated at 34. The system then preloads a dialing queue 35 with a certain number of records from the calling data. As the dialing process begins, the system manages the number of calls being made at any one time based on the number of operators that are available to receive calls. When a connection is established to a client, the system routes the call to an available operator and displays the client's record on the operator screen. The operator is now ready to make the presentation to the client and record information from the transaction on the display screen. Once the operator completes the call, he or she presses a designated key on the keyboard to record the status of the contact and terminate the call. The system then makes the operator station available for another call.
After the operator has pressed the designated key, the system validates the client's record in an output call list 36, and, depending on the outcome of the call, separates the record in the corresponding output file at 37. For example, if the particular person to be contacted is not at home, the operator may press a key telling the system to place the client's record into the call-back file 38. When, for example, a call results in a future follow-up call, the operator presses another key to immediately print information of the transaction on a printer, as indicated at 39.
Records which require no further action (i.e., a sale is made, wrong number, etc.), are marked complete and are not put into the call-back file but instead are put in a sale file 40.
When all the numbers have been exhausted in the campaign list, the system automatically begins a statistical analysis of both operator and campaign performance, as indicated at 41. Finally, a closeout function 42 is performed during which all relevant data of the campaign is written to a tape 43 or disk 44, or transmitted to a host computer 45.
The goal of any call origination management system is to have each operator connected to each call answered. Under these conditions, there would be maximum talk time and no nuisance calls. To accomplish this, however, requires a prior knowledge of the time it takes to connect a call and exactly how long each operator talks. In practice, both of these can be highly variable, within limits. The system cannot predict exactly when or if a placed call will result in an answer and, of course, the amount of time an operator talks will depend on the responses of the client. Therefore, scheduling the next answered call to occur exactly when an operator finishes talking, is impossible. An answer may occur before or after the operator finishes the previous call, and the result is an increase in the nuisance call Pate or an increase in operator idle time, or both. Intuitively, it is clear that the system variables which affect talk time are the ratio of answered calls to the number of call attempts per session (A.sub.ratio) and the average conversation time per call session, (CON.sub.time). The system goal is a maximum talk time per operator with a minimum of nuisance calls.
Call pacing algorithms are used in the prior art to determine when and how many calls to place in order to maximize operator talk time. U.S. Pat. No. 4,933,964 to Bassem M. Girgis and assigned to the assignee of this application, discloses an adaptive pacing algorithm based on an analysis of the duration of calls, and is incorporated herein by reference.
In the Girgis pacing algorithm, the algorithm determines the number of calls to dial as an inverse function of the mean time of all calls and the standard deviation multiplied by a first constant. This first constant is a function of the ratio of nuisance calls to the number of call attempts but is not a definite mathematical function. It is, instead, determined experimentally to be .+-.0.25 of the standard deviation and varies within the .+-.0.25 range depending on how far the ratio of nuisance calls deviates from a set level. The number of calls to dial is also an inverse function of a second constant times the ratio of the answered calls to the call attempts per session minus the maximum allowable ratio of nuisance calls to call attempts. This second constant is itself a function of the mean time ratio of answered calls to the number of call attempts during the session and the ratio of nuisance calls to the number of call attempts, but it has been determined empirically. As the session progresses, new values of the ratio of answered calls to attempts per session, the mean time and the standard deviation are computed, and these new values are used in determining the number of calls to dial.
Call pacing algorithms such as that disclosed by Girgis are generally satisfactory. However, such prior art systems result in what, in some circumstances, is an unacceptable number of nuisance calls if the system efficiency is maintained at a high level in terms of talk time.